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Hanagement Summary 


The Interactive System Productivity Facility (ISPF) is an IBM product 
that improves productivity in the development of interactive 
applications. Introduced in 1981, use of ISPF has grown tremendously 
during the past several years. This growth can be attributed to the 
variety of user application requests that can be satisfied using (SPF. 
Because of the expanding usage of ISPF, it is becoming increasingly 


important for installations to have a method of standardizing ISPF 
development. 


GUIDE membership has recognized and addressed this need by developing an 
ISPF standards and guidelines document. This document, which represents 
the combined expertise of many corporations, contains concise and clear 
development standards that reflect the experiences of corporations from 
around the country. Use of the "GUIDE ISPF Standards and Guidelines" 
document will bring to your shop a formalized ISPF development 
methodology that will maximize the usage of ISPF dialogs and improve the 
productivity of your dialog developers. 


Listed below are some of the many benefits that you will realize by 
incorporating these standards and guidelines into your environment. 


1. AUTOMATIC STANDARDS REVISIONS 
With each new release of ISPF, GUIDE membership reviews and updates 
the document to keep it current with the product's technology. 


Therefore, GUIDE will insure that your installation's standards wil} 
keep pace with your ISPF environment. 


2. REDUCED DEVELOPMENT AND MAINTENANCE COSTS 
The document defines a repeatable approach to dialog development so 
that dialog developers do not have to "re-invent the wheel!’ with 
every new ISPF dialog application. This reduces application 
development time. Maintenance costs are also reduced because the 


dialog developer spends less time becoming acquainted with each 
application. 


3. APPLICATION PORTABILITY 
Adherence to standards promotes consistency between applications. 
lt enables dialogs to remain uniquely identifiable while allowing 
them to function in a shared environment. This promotes 


portability; from user to user, CPU to CPU, and data center to data 
center. 


4. PRODUCT COMPATIBILITY 


IBM, as well as many of the more prominent vendors, conform to 
dialog development standards similar to those outlined in the "GUIDE 
ISPF Standards and Guidelines" document. By adhering to these 
standards, your applications will use conventions like those used in 
most major products available in today's market. This enables your 
environment to be more “user friendly'' by promoting consistency 
between products and applications. It also reduces user training 
requirements because applications look and function in a similar 
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manner. 


The "GUIDE ISPF Standards and Guidelines" publication is available to 

_ all GUIDE members. Use of it will enable your shop to take advantage of 
the latest techniques in ISPF dialog development. It will truly be an 
asset to your environment. 
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CHAPTER: 1 - Introduction 


l. INTRODUCTION 
This publication is intended to meet the needs of ISPF installations 
which are developing their own ISPF dialogs or installing IBA or other 
vendor products which use ISPF as their dialog manager. This is a 
continually evolving document and wil! be updated as necessary. 


The objectives of this publication are to: 


1. Establish STANDARDS for ISPF dialogs based on widely accepted 
practices which are consistent with the structure of the PDF prod- 
uct or use an ISPF or PDF function which has certain requirements. 
lt is strongly recommended that each installation adopt and en- 
force these practices for their own internal standards. 


2. Suggest GUIDELINES (naming conventions, library concatenations, 
making changes to system-wide dialog components, etc.) based on 
widely accepted practices which will enhance the usability and 
effeciency of PDF based user or vendor dialogs. 


This document addresses standards for dialogs which operate in a_ PDF 
environment since PDF has the broadest base of users. Major emphasis 
is placed on how a dialog looks to the user (panel layouts, message 
formats, etc.). Other uses of ISPF dialog manager, such as developing 
prototypes for any on-line application (i.e. CICS, IMS, etc.), do not 
need to adhere to the standards and guidelines proposed in this docu- 
ment. 


Points which are considered STANDARDS are identified by bold, itali- 
cilzed text. All other points are considered guidelines. 
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2. NAMING STANDARDS 
2.1 GENERAL 


Naming standards must be established for the member names of ISPF com- 
ponents (panels, messages, CLISTs, etc.) to prevent member name con- 
flicts. Member names should also identify the dialog or application 


in which the member is used or the group which developed the dialog or 
application. 


Conflicting member names are a concern because most installations run 
ISPF as a concatenation of libraries from different sources. The IBM 
1SPF and |ISPF/PDF libraries are concatenated with other vendor’ ISPF 
libraries and with libraries of dialogs developed at the installation. 
Some installations have many different ISPF libraries corresponding to 


different groups of users. If no naming convention has been estab- 
lished, libraries which contain members of the same name may be con- 
catenated. When multiple members of the same name exist ina 


concatenation, only the first member found with the specified name is 
accessible. 


There may not be any one naming standard which is appropriate for ev- 
ery installation. The purpose here is to propose several possible 


naming standards and discuss their relative advantages and disadvan- 
tages. 


Naming conventions should be established for all parts of the dialog 
(panels, messages, skeletons, CLISTs, tables, programs). Naming con- 
ventions should be established for all Profile pool variables within a 
given profile (identified by the NEWAPPL id). Naming conventions 


should be established for all Shared pool variables within a given 
NEWPOOL. 


2.2 REQUIREMENTS 
Any naming standard should meet the following requirements: 


1. Member names must be unique across any libraries which are concat~ 
enated together. If the System Modification Program (SMP) is to 
be used to maintain the dialogs, each distinct component of each 


dialog must be uniquely named across all libraries that SMP wil] 
maintain. 


2. The member name_ should identify the dialog or application which 
the component belongs to. The naming standard should also accom- 
modate components which are used by many different dialogs. 


CHAPTER: 2 - Naming Standards 


3. 


The naming standard should use as few characters as possible, so 
that the dialog developer has some characters for his/her own use. 
Because the length of the names is limited to 8 characters, each 
character required by the naming standard must be justified. 


In addition to the above, the naming standard should, ideally, encour- 
age the use of mnemonics in names. Well-chosen mnemonics are useful 
in communicating information about the function of the component. 


2.3 


IDENTIFIERS 


The member name should include some of the following identifiers: 


1. 


SYSTEM ID - identify the system to which the dialog belongs 


A system id identifies the application system but not the dialog 
to which a specific component belongs. A list of system ids must 
be maintained to ensure uniqueness. 


Dialog components should not be named with a prefix of either ISR 
or ISP since this may conflict with elements distributed by IBM. 


GROUP ID - identify the group or department which developed the 
dialog 


If group id is used, the group which is responsible for the dialog 
is easily identified when problems occur or changes need to be 
made. This may not be important if each group has its own set of 
ISPF libraries concatenated. A list of group ids must be main- 
tained to ensure uniqueness. 


DIALOG 1D - identify the dialog to which the member belongs 


Member names which identify the dialog to which the member belongs 
are useful in maintaining the ISPF libraries. All components of a 
dialog can be identified if each member name contains a dialog ID. 
When a problem with a specific member is found, it is easy to de- 
termine which dialog and which other ISPF components may be af- 


fected. If dialog id is used, a list of dialog ids must be 
maintained to ensure uniqueness. 


Dialog id could be used in conjunction with system id or group id 
to further identify the component. For example, system id or 
group id could be defined as a 3-character code‘and dialogs within 
each system/group could be identified by a I-character code. 


i 
t 
| 
f 
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TYPE - an identifier Indicating the type of ISPF component (pan- 
els, clists, skeletons, etc.). Im some cases this could even be 
broken down further) types of panels, for example. 


The type indicator is useful in naming components which are main- 
tained by SMP (because every member name must be unique across al] 
libraries maintained by SMP). It can also be useful in differen- 
tiating between the different types of panels within a panel li- 
brary. 
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2.4 SOME NAMING STANDARDS WHICH ARE IN USE NOW 


It its important that each installation develop a standard for naming 
dialog components that will fit their needs. Some guidance Is pro- 
vided in this section through examples to assist in this development. 


Because of the connection between message-ids and message member 


names, some of the following naming conventions cannot be applied to 
message member names. 


The number of characters specified in the following naming standards 
are given as an example. Each installation will have different re- 
quirements for the number of characters used for an identifier. 


Ls 
Characters Value 


1-4 Dialog 1D / Group ID / System ID 
5 Type of component 
6-8 specified by developer 
Comments - this convention allows the dialog developer to choose a 


meaningful naming scheme for part of the member name, while still 
providing information which is useful in identifying the compo- 


nent. 
2% 
Characters Value 
1-3 Dialog 1D / Group ID / System !D 
4 Type of component 
5-8 each character is an alphameric 


character which indicates the option 
number at the at the Ist, 2nd, 3rd 
and 4th level of the dialog hierarchy 


Advantages - the member name indicates where the ISPF component be- 
longs in the dialog hierarchy. 


Disadvantages - If the organization of the dialog is changed, the 
member names would need to be changed to reflect the new hierar- 
chy. 


Characters Value 


} Type of component 

2-5 Dialog 1D / Group ID / System ID 
6 alphanumeric character 

7-8 Version 
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Advantages - Version may be useful information for some instal la- 
tions. 


Disadvantages - Only 1! character is left for the developer to spec- 
ify. Also, in a member selection list, the different types of 
panels which belong to a dialog are not grouped together. 


4, 
Characters Value 
1 Installation Code 
2-4 Dialog ID / Group ID / System ID 
5 Type of component 
6-8 specified by developer 
Comments - Installation code may be useful information for instal- 


lations which support more than one operating system. 
5. tBM has no PUBLISHED naming standards for their ItSPF member names. 
For the ISPF and ISPF/PDF products, they GENERALLY follow a conven- 
tion of 


Characters Value 


1-3 ISR or ISP, depending upon the product 
to which the member belongs 
h ISPF/PDF option ID (e.g. E for Edit) 
5-8 free-form 


Installations should not begin member names of dialog components 
with the characters ISR or ISP because of this: convention. 
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3. PANELS 


3.1 OVERVIEW 


1. Panels should be as similar in appearance as possible. 

2. Where differences exist between the way two panel types work, 
there should be differences in appearance between the two types. 
These differences wil! serve as visual clues into the function 
available on/with the different panel types. 


3. The above applies to data/information fields as well. 


3.2 PANEL LAYOUT 


1. FORMAT DIAGRAM 
The panel format in Figure 1 provides a basis for the following dis- 
cussion on panel layouts. The terms used in the description of each 


panel type are defined below. 


-~------------------ TITLE LINE ---------------------- 


Function and/or Instruction Line 


---------- > Body of Panel 
or Text Lines 


(Directive Line) 


Figure }. GENERAL PANEL FORMAT 


2. TITLE LINE (LINE 1) 


a. Should be the first line on the panel. 
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b. 


C. 


Should be displayed in a high intensity output field. 
Should be in upper case. 


The title should be centered on the title line. 


Separate the title from the dashes by at least 1 (and prefera- 
bly 2) blanks. 


The word TUTORIAL should appear on both ends of the line for 
tutorial panels. 


Always use the default message area to display messages. This 
is an important part of the format to which dialog users have 
become accustomed. The default area for the short message 15s 
the upper right hand corner of the panel (line 71). 


Short messages should always be displayed with all 24 charac- 
ters (right justify the message and pad with blanks). 


3. COMMAND LINE (LINE 2) 


a. 


All panels must have a selection “option,” or "command" field. 
The "selection" field is used on tutorial panels, the “option” 
field is used on menu panels, and the “command” field is used 
on al] others. The only allowable formats are: 


Selection ===> 
or 

Option ===> 
or 

Command ===> 


Should be in upper case. 
Should be displayed in a high intensity output field. 


The input field should only be terminated at the beginning of 
the next line. 


On scrollable panels, the command line contains a 4-byte 
scroll field. It should begin in column 64 and have the fol- 
Towing text field preceed rt: 


SCROLL ===> 


4. LONG MESSAGE LINE (LINE 3) 


ra 


Should always be blank. (Some non-essential output fields may 


be positioned on this line. This is the normal position for a 
time-of-day field). 
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b. Time-of-day field, if displayed, should be placed on the third 
line on the right hand side of the screen. 


FUNCTION LINE (OPTIONAL, LINE 4) 


a. Can be used to display a subtitle on a panel, if one is neces- 
sary. 


b. Should be in upper and lower case, centered on the line. 
c. Should be displayed in a high intensity output field. 
INSTRUCTIONS 


a. Can be used with or without a function line. To provide the 
user with information on what Is to be entered on a panel when 
it may not be clear from the content of the panel. In- 
structions should be low intensity, upper and lower case. The 
position of the Instructions depends on panel type, unless 
otherwise noted. 


b. They should be used only when necessary and be as brief as | 
possible and should always be in an active form. Use tutorial 
and help panels for lengthy explanations. 

The following panels have unique requirements: 


1) Scrollable Panels (specifically their display). 


Consist of one or more Jines which instruct the user 
on the function of this panel. 


Should include a list of the valid select codes (line 
commands) . 


2) Tutorial Panels 


Can be used anywhere on the panel after text lines and 
before select option (if any). 


Used specifically in instructing the user on navigat- 
ing through the tutorial. 


Should read: "The following topics are presented in 
sequence, or may be selected by number:" or "The fol- 
lowing topics are presented only if selected by num- 
ber:" 
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7- BODY OF PANEL 


a. General 


The layout and format of the body of the panel varies, depending 
on function. Specific body requirements for each type follows in 
the next chapter. 
The Types are: 
1) NonScrollable 
Data Entry 
Multi-Column Data Entry 
Confirmation 
ipopaation 
Tutorial Text 
2) Scrollable/Dynamic 
Table Display 
Dynamic Panel/Graphic Areas 
3) Selection 
Menu 
Tutorial Menu ~ 
4) Non-Display 


Within the body there are input, output and text fields. Every 
panel will have some or all of these fields and they al] must con- 
form to the following: 


1) Whenever possible the user should have a choice of attri- 
butes for a field. 


2) Do not change the default attribute characters unless one 
of the default characters must appear within the text of 
the panel. 


3) Input fields should be initialized to either a previously 
entered value, or a default value, if one can be deter- 
mined. 
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4) Padding 


a) Unused padding characters should not need to be re- 
moved by the user (i.e. use the PAD keyword fa the 
JATTR section of the panel to pad input fields). 

b) If it is necessary to pad an input field with some- 
thing other than null characters, always pad with the 
user's defined pad character unless special applica- 


tion requirements dictate otherwise. This is mainly 


if the user MUST see the exact length of the input 
field. 


S) Be consistent in the use of displayed values (i.e. always 
use “¥" and "N" or "YES" and "NO"). 


6) To minimize keystrokes use TRUNC and TRANS in the /PROC 
section of the panel definition. If this ts done, the 
same displayed values should always be truncated or trans- 
lated consistently throughout the dialog. 

b. Specific Field Types: Format and Design Considerations 


1) General 


2) Input Fields: Singly Occurring 


+Description Field¢===>_Input Field + (Information) 


a) Description field 


i. Should be brief, limited to one line when possible 
and never exceeding two lines. 


ii. Should be lined up to the left of or if necessary 
placed just above the corresponding input field. 


iii. Should be displayed in a Jow intensity output 
field. 


iv. Should be in upper and lower case. 


b) Standard Arrow Symbol ( ===> ) 


i. All input fields should be immediately preceded by 
the ISPF standard arrow symbol ( ===>). 


iit. Should be used ONLY to precede input fields. 


= 3. = 
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3) 


c) 


d) 


iit. Should always be displayed in a high intensity 
output field. 


iv. Line ap the arrows vertically, within logical 
groups, on the panel. If possible, line up all of 
the arrows on the panel. The text fields which 
precede the arrow symbols should be left-justified 
withia logical groups. 


For example: SYSOUT CLASS ===> 
LOCAL PRINTER ID === 


Input Field 
i. Should be displayed using high intensity. 


Information 


i. Used to display the possible values for the corre- 
Sponding tnput freld. 


ii. Should be displayed in a Tow intensity output 
freld. 


iii. Should be in upper and lower case. 


iv. The recommended values for Yes/No fields are Y and 
N. 


v. If there are only 2 valid entries for an input 


field, list the entries separated by ‘or', (i.e. Y 
or N) to be consistent with ISPF/POF panels. 


vi. To list more than two valid entries for an input 
field, separate the items by a comma and a blank. 
For example, !SPF/PDF Version 2 uses the following 
format on its 3.4 panel: 


(QUICK, SHORT or LONG) 


Input Fields: Repeating 


a) 


For vertically repeating fields 


i. Should be arranged in a columnar fashion beneath 
their respective headings. 


ii. Most should be displayed using low intensity; 
highlight only the most important fields. 


o: Pie 
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4) 


5) 


b) 


c) 


- Panels 


iii. Should be padded with the user's defined pad 
character. 


iv. Align numeric data to the right when a table is 
displayed by storing the values in the table with 


the correct number of leading blanks or by using 
JUST (RIGHT) . 


For horizontally repeating fields 


i. Should be proceeded by the standard ISPF arrow 
symbo| (===>), 


ii. Should be displayed in a high intensity input 
field. 


tii. Should be padded with the user's defined charac- 
ter. 


The Select Field 
i. Should be the left-most field for ease of use. 


ii. Should be displayed in a high intensity input 
field. 


iii. For functions that have ISPF/PDF equivalents, use 
the same code, i.g. 


B - Browse 
D - Delete 
E - Edit 

P - Print © 
S - Select 


iv. If selection codes differ from their use in 
ISPF/PDF, then the instructions should state this. 


Output Fields 


a) High intensity - should be used sparingly. Low inten- 
sity should be the predominant attribute for fields in 
the body of the panel. 

b) Should not be padded with any characters other than 
nulls or blanks. 

Text Fields 

a) High intensity should be used sparingly. Low intensity 


Should be the predominant attribute for fields in the 
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body of the panel. The only universally highlighted 
sequence of characters are the title line, the command 
line, and the arrows preceding the iaput fields. 


b) Use upper and lower case in text fields; it has proven 
to be more readable than text which is all in upper 
case. 


8. TEXT LINES 


The text lines are used to give the user a brief description of the 


current dialog status. They are primarily used in informational and 
confirmation panels. 


a. 


Informational 


1) Should be a brief explanation of the processing status. 


2) Should be displayed using low intensity, and highlighting 
only important information. 


Confirmation 


1) Should be a brief explanation of the situation which re- 
quires confirmation. 


2) Should be displayed using low intensity, and highlighting 
only important information. 


Tutorial 
1) Should highlight only important information. 
2) When explaining a dialog input field, display the field on 


the tutorial panel as it appears on the dialog panel (ex- 
cept that it should be a text or output field/. 


9. DIRECTIVE LINE 


The directive line directs the user on how to proceed from this panel. 
The wording of the line should be consistent with ISPF/PDF and varies 
depending on panel type. 


a. 


Non-Scrollable Panels 


1) To indicate an action, display the following on line 23 
(code so the entire message is on one line): 


Press ENTER key to process; 
Enter END command to terminate. 
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2) 


3) 


4) 


5) 


If ENTER and END meanings are different from normal PDF 
use, use two lines to display the instructions (this wil! 
help draw attention to the instructions) : 


Press ENTER key to --------- 
Enter END command to ------- 


where dashes indicate action. For example, 


Press ENTER key to DELETE the data set 
Enter END command to CANCEL the delete request 


If two directive lines are necessary, place them on lines 
22 and 23. 


The directive line(s) should be in the following format. 
the words END and ENTER are in upper case and displayed in 
high intensity output fields, the rest of the line{s) 
should be in upper and lower case and displayed in Tow 1n- 
tensity output fields. 


Example of a standard format directive line, coded using 
default attribute characters (code on one line): 


+PresssENTER+key to process; 
EntertEND+command to terminate. 


Scrollable Panels 


1) 


Instructs the user on how to exit from the table display 
or from dynamic panel areas. Wording should be similar to 
non-scrollable. 


Menus 


1) 


A directive line may be used to explain how to return to a 
higher level selection menu. 


Tutorials 


1) 


2) 


3) 


In tutortals, the directive line is only used on a panel 
which continues to another panel. The correct format of 
the directive line is: "(Continued on next page/” 

Should be displayed in a high intensity output freld. 


Should be consistently placed within the body of the panel 
(preferably centered on line 23). 
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DESIGN CONSIDERATIONS 


Installation-developed panels must be consisteat with the format 
of ISPF/POF panels. 


To display large amounts of information, use more panels with less 
information per panel rather than fewer panels with more informa- 
tion per panel. 


The majority of the panel should be displayed in low intensity 
output and 1n upper and lower case. 


Do not overuse high intensity. High intensity draws attention to 
important fields on a panel when it contrasts with the majority of 
the panel fields. Too much high intensity on a panel minimizes 
this effect. 


Be careful tn the use of extended data stream attributes (color, 
highlighting, etc.) The user needs to know where to focus his/her 
attention on the screen. An excess of color and/or highlighting 
on a panel 1s confusing and can also cause eye fatigue. The use 
should determine the color attribute whenever possible. A panel 
design dependent on color may be invalid if any user of the panel 
has any form of color blindness. 


All dialogs should make use of the HELP facility. All panels must 
have an associated HELP panel or, at the very least, @ general 
HELP panel as opposed to no HELP at all. 


Fixed panel formats should generally be designed for an installa- 
tion’s smallest screen size. Vendors must design their products 


to operate on the smallest screen ISPF supports (24 rows by 80 
columns). 


The last line of a "fixed" panel should always be blank to allow 
the user to split-screen without losing any information. 


The dialog developer should also consider the PFSHOW command when 
designing panels. Up to four additional lines may be left blank 
at the bottom of the screen to accommodate PFSHOW output. An al- 
ternative is to place descriptive information which a more experi- 
enced user may not care about on these lines. PFSHOW output would 
then overlay an area of lesser importance or at least of lesser 
concern. For non-scrollable panels, input fields should line up 
vertically, if at all possible. This allows the most effective 
use of the cursor positioning keys. 


- 18 - 


11. 


13. 


15. 


1]. 


18. 


CHAPTER: 3 - Panels 


Be careful when using Dynamic Areas for ERROR/HELP information. 


Dynamic Areas are cannot be pre-processed and may hinder perform- 
ance goals. 


Identify panels with comments (who, where, calls who, called by, 
etc.) in the )ATTR section of the panel definition. 


All panel definitions should contain all sections - the /ATTR, 
/BOOY, JREINIT. JINII and JPROC. Any sections which are not actu- 
ally used by a panel should be left empty. Table display panels 
should also contain a JMODEL section. This can be re-enforced at 


an installation by encouraging the use of MODELS for panel devel- 
opment. 


. Most used, or required input fields should be placed near the top 


of a panel with less important, lesser used, or optional fields 
lower down. 


To minimize keystrokes use TRUNC and TRANS in the )PROC section of 
the panel definition. if this is done, the same displayed values 


should always be truncated or translated consistently throughout 
the dialog. 


. Minimize the use of lengthy application commands within a dialog. 


Panels should be used to build and issue any lengthy commands. For 
example, assume the following command is used to perform a search: 


SEARCH TABLE FIRST(JOHN) MIDDLE (Q) LAST (DDE) 
FOR (EMPLOYEE_NUMBER) 


The user should not be required to enter the command. Instead, the 
dialog should use panels to gather the information and should con- 
struct and issue the command. 


When designing a scrollable panel with a select field, put the se~- 
lect field on the left hand side of the screen. 


Each line should begin with the panel's low intensity output at- 
tribute character unless some other attribute is necessary. This 


prevents unintentional continuation of a field from the previous 
line. 


When writing dialogs to be used by non-programmers, consider using 
the word “screen” instead of “panel” in panel text which refers to 
panels being displayed. “Screen” is the correct term for the 
physical tmage displayed on the terminal and is also more likely 
to be understood by non-programmers. 


For non-scrollable panels, input fields should line up vertically, 


if at all possible. This allows the most effective use of the 
cursor positioning keys. 
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19. For scrollable panels (table displays), each row should constitute 
a logical grouping of data. 


Align numeric data to the right by storing: the values in the table 
with the correct number of leading blanks or by using JUST (RIGHT). 
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a 3 3.4 FORMAT FOR SPECIFIC PANEL TYPES 


1. Non-Scrollable Panels 


a. Data Entry Panel 


COMMAND ===> 
Instructions 
DESCRIPTION FIELD 1 ===> INPUT FIELD 1 (information) 
DESCRIPTION FIELD 2 ===> INPUT FIELD 2 (information) 
DESCRIPTION FIELD 3 ===> INPUT FIELD 3 (information) 


Directive Line 
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b. Multiple Column Data Entry Panel 


=<< 556 TITLE FOR MULTIPLE COLUMN DATA ENTRY PANEL----- 
COMMAND ===> 
Instructions 
Heading | Heading 2 Heading 3 Heading 4& 


=—S ee we we S| or _ ww 2 ee = @ @ oF fneeewenweee = 


e Should be organized so than the user enters data across @ 
row instead of down a column. In other words, logical 
groupings of data (e.g., data items related to a single 
record) should be input across a row, not down a column. 
The reason for this is than the cursor can be moved across 
the screen more easily than it can be moved down the 
screen. 


Columnar Headings: 
© Should normally be left-justified. 


e Should be displayed in a high intensity output field. 
e Should be in upper and lower case. 
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c. Information Panel 


------------ TITLE FOR INFORMATION PANEL -----~-- ----- 
COMMAND ===> 


Text lines 


® When a dialog function executes for a long time without 
any user interaction (e.g. when searching a large file), 
an INFORMATION panel may be used to inform the user of the 
status of the processing. The panel itself is a standard 
panel containing only text fields. Before the panel is 
displayed, the CONTROL service is invoked with the DISPLAY 
and LOCK parameters. The panel is displayed with the key- 
board locked and the function continues processing without 
waiting for any user response. 


e Although the user cannot respond to the pane! (other than 
by using the "break" key), the dialog has informed the 
user of its status. An information panel can be used to 
give the user an idea of how much processing has been done 
and how soon it will be finished. 
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d. 


Confirmation Panel 


COMMAND ===> 
Text lines 


Directive lines 


e When a user must confirm an important function (e.g. file 
deletion, record update) in a dialog, a confirmation panel 
may be used. The text lines of a confirmation panel are 
used to describe the process or function of the task. The 
directive line directs the user and describes what process 
will occur based on user action or input. - 


>) 


_—/~ 


\ 


CHAPTER: 3 - Panels 


Tutorial Text Panel 


TUTORIAL----- TITLE FOR TUTORIAL TEXT PANEL---- TUTORIAL 
COMMAND ===> 


Tutorial Text 


Directive Line 


e Set &ZUP on every tutorial panel. 


e Whenever necessary, use continuation tutorial panels to 


explain a dialog panel. Using more panels with less text 
per panel is more effective than using fewer panels with 
more text per panel. 


e All dialogs should have an overview topic included in 


their tutorial. An overview is useful for orienting users 
who are unfamiliar with the dialog. 
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2. Scerollable Panels 


Table Display Panel 


Tare See aes es TITLE FOR TABLE DISPLAY PANEL ---errrceromnn- 
COMMAND ===> SCROLL ===> 
Instructions 
Directive Line 

Column2 Column3 Column4 Column5 
Select Heading Heading Heading Heading 
aa ea a (end of panel example) -------- 7 o-oo nnn 


e For table displays that use more than one screen line to 
display one row of the table, a line of dashes (or a blank 
line) may increase the readability of the display. 


e Should be organized so that the user enters data across a 
row instead of down a column. In other words, logical 
groupings of data (e.g. data items related to a single re- 
cord) should be input across a row, not down a column. The 
reason for this is that the cursor can be moved across the 
screen more easily than it can be moved down the screen. 


Column Headings: 


© Should normally be left-justified. 


© Should be displayed in a high intensity output field. 
© Should be in upper and lower case. 


Dynamic Panels/Graphic Areas 


1) Use of dynamic and graphic areas must always observe the 


Standards for panel layout (e.g. title line, command line, 
fig.). 


2) Dynamic areas can be used in conjunction with parts of 
other panel types and fields (singly occurring input 
fields on data entry panels, etc.) but the format must be 
consistent with that type of field. 
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Selection Panels 


Menu Panel 

ie a cian ea ae TITLE FOR SELECTION MENU--------~------- 
OPTION ===> 

Instructions 

] OPTION 1 - Brief description of option |] 

2 OPTION 2 - Brief description of option 2 

3 OPTION 3 - Brief description of option 3 

L OPTION & - Brief description of option 4& 

X EXIT 


Directive Line 


Align each of the three sections vertically. 


Put the options with the highest probability of being chosen 
at the top of the list to reduce reading time. If there is 
no obvious pattern for ordering options, put them in 
alphabetical or numeric order. 


lf both alphabetic and numeric options are used on a menu, 
list the numeric options in order first, followed by the 
alphabetic options, in order. 


When the x (EXIT) option is displayed, place it near the 
bottom of the panel, distinctly separated from the rest of 
the options. 


For those options which correspond to ISPF/PDF options, use 
the same Option Codes and Option Titles as are used in 
ISPF/PODF. 


Option Lines: 


Option Code 
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Should be numbers (preferred) or capitalized letters. 
Should be on separate lines. 
Use Arabic numerals, aot Roman numerals. 
Should be displayed in a high intensity field. 
Must not use ‘.’ or ‘I’ with the Option Code. 
Use ‘X’ for EXIT only. 
° Option Title 
Should be in upper case. 
© Option Description 
Should be worded as a statement, not as a question. 


Should begin with a capital letter. 
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b. 


Tutorial Menu 

TUTORIAL--TUTORIAL SELECTION MENU TITLE--TUTORIAL 
OPTION ===> 

Tutorial Text 

Instruction Line 


1 - Brief Description of Option 1 
2 - Brief Description of Option 2 


e Set &ZUP on every tutorial menu panel. 

e Use a tutorial hierarchy that has a logical order (i.e. 
follows the hierarchy of the dialog). Ideally, there 
Should be a minimum of one tutorial panel for every dialog 
panel. 

@ All dialogs should have an overview topic. An overview is 
useful for orienting users who are unfamiliar with the di- 
alog. 


Tutorial Text: 


e Should be displayed using low intensity, and highlighting 
only important information. 


e When explaining a dialog input field, display the field on 


the tutorial panel as it appears on the dialog panel fex- 
cept that it should be a text or output field). 


Option Lines: 
@ Option Code 
Should be numbers (preferred) or letters. 
Should be displayed in a high intensity output field. 


When a tutorial option corresponds to a selection menu 
option, the same option code should be used for both. 
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If the characters 8, S, T, U, or I are used as se- 
lection options on a tutorial panel, the user will not 
be able to use these abbreviations to specify the tu- 
torial commands BACK, SKIP, TOP, UP, and INDEX. The 
full tutorial commands will still function. However, 
if B, S, 1, U, or I do need to be used as tutorial 
options thea the user must be iaformed of the need to 
use the full tutorial command to execute that fuac- 
tion. 


e Option Description 


Describes the specific area covered by the tutorial 
option. 


Align the option codes and the option descriptions 
vertically. 


Put the options with the highest probability of being 
chosen at the top of the list to reduce reading time. 
Match the order of the options to those found on the 
corresponding Selection Menu. If there is still no 
obvious pattern for ordering options, put them in al- 
phabetical order. 


Non-Display Panel 


a. 


The format of a non-display panel should be the same as that 
of an !nformation panel since the CONTROL NONDISPL services 
might be changed to a CONTROL DISPLAY LOCK during development 
of the application. The panel could then be used to help de- 
bug the application. 
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4.1 


4.2 


4, MESSAGES 


GENERAL 


All messages should be clear, concise, in plain language and in 
vocabulary that is familiar to the user. In a panel message if 
more information is needed provide it in the long message area. 


Use standard punctuation. 


Messages should have a consistent format. Place any user action 
first in the long message, followed by an explanation of the error 
or the consequences of the action. 
Use positive statements wherever possible, e.g. 

"Select an option from the list below" 

instead of 

"Option selected is invalid". 
Use active rather than passive statements, e.g. 

"Enter the name of the data set" 


instead of 
"Data set name must be entered! 


Do not use CLIST, EXEC or program output facilities to display 


Pip All messages should be displayed using the ISPF message 
Facility. 


SPECIFIC 


Always use the default message areas to display !SPF messages. 


Messages should not overlay any panel fields (other than text 
fields used to display time-of-day, date or userid). 
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Each message should have both short and long text except. If a 
short message cannot be meaningful enough, a long message should 
be displayed immediately (without a short message). This Is to 


avoid cryptic short messages. A HELP panel should be associated 
with each message. 


Always use .ALARM#YES with error messages 


but error messages only. ‘".ALARM=YES" stops commands stacked on 
the COMMAND line. 


Informative messages, when used consistently are very helpful and 
reassuring to users. They should be used wherever it is appropri- 


ate in the dialog to inform users of actions that are taking 
place. 


The .HELP parameter should be used whenever there is a specific 
tutorial panel which relates to the message. 


Position the cursor to the field in error when a message is dis- 
played; this helps the user to find and correct the error. 


Use the value from the field in error in the long message to in- 
crease the informational content (the same value should be dis-~- 
played in the short message, if possible). 


Use dialog variables in messages to make the message more meaning- 
ful. When possible, the dialog variable should be used in both 
the short and long message. For example, an input dialog could 
display the record number that was processed as part of the "re- 
cord processed" short and long messages. 


lf processing efficiency is an important consideration, guidelines 
may be established concerning the size of message members. Message 
members will be accessed most efficiently if the total size of the 
member is kept under the blocksize of the data set. For example, 
if the blocksize of the library is 6160 (the recommended 
blocksize), then a message member of 77 lines (77 x 80 = 6160) is 
the maximum that will fit in one block. 


Short messages should be uppercase with not message numbers; tong 
messages should be upper/lower case. 
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Whenever possible, long messages should include unique message 
numbers. This allows for easier communication and reference and 
reduces language dependency. Documentation, both on-line and in 
printed form should reference these message numbers. 


Log messages should include, at the least, the same information 
that is displayed on the screen when information for an action is 
written to the log as well as being displayed on the panel In this 
manner the user can easily identify the message in the log with 
the activities of the session. The following will accomplish 
this: 


ISPEXEC SETMSG MSG (DTSMO01) 
ISPEXEC LOG MSG (DTSM001) 


The GETMSG service should not be used to generate messages for 
display on a panel or for placement in the log. Standard methods 
(such as the SETMSG or LOG services) should be used to directly 
create the required message. The GETMSG service should be used 
only when it is necessary to place the message information in a 
location other than a panel or the log. For example, the GETMSG 
service should be used when extracting information for placement 
in an application audit trail data set. 


. Messages should indicate exactly what values, actions or fields 


the messages are referring to. In panels, the additional use of 
cursor positioning is useful to enhance this. 
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5. TABLES 


5.1 GENERAL 


Tables should only be used for one-to-one mappings. ISPF tables were 
designed to provide a way to store, process and display a basic array 
structure. Attempts to use ISPF tables as a sophisticated database 


will result in extremely complex (and slow) table processing logic. 
Do not use a table row as a linked list. 


5.2 SPECIFIC 


1. Do not redefine the scroll PF keys to different functions. User 
confidence is undermined when the meanings of the PF keys change 
from one dialog to another. 


In the event that you must redefine the scroll PF keys, encourage 
the use of the PFSHOW command so users can see how keys are de- 
fined. 


2. If possible, do not use extension variables in a table. — The 
presence of extension variables will add complexity to table proc- 
essing which will make the dialog harder to maintain. Using ex- 
tension variables in permanent tables will complicate the logic of 
every dialog which accesses the table. 


Extension variables may be necessary for displaying error or in- 
formational messages within a table row. 


3. Display informative messages during user processing of the table. 
When the message is related to a function command, use the ISPF 
message facility. When the message is related to a particular 
row, display the message in a column of the table display which 
has been reserved for that purpose. For permanent tables, this 
can be best accomplished by using an extension variable to display 
the message. For temporary tables, define a message field in each 


row when the table is created, to avoid the use of extension vari- 
ables. 


4. The first rnput field in the table display should be the Jeftmost 


field. To be consistent with ISPFIPDF table displays, this field 
Should start in column 7. 
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Emulate PDF processing of tables as closely as possible (for exaa- 
ple, member selection lists ia POF option 3.1). 


The processing of the command field can be done either before or 
after processing the rows. To provide PDF consistency, however, 


processing the command field after processing the rows is sug- 
gested. 


When designing a dialog which displays tables, a decision must be 
made about the processing of the END and RETURN commands. When the 
user enters END or RETURN, there may be row modifications and/or 
application commands which have not yet been processed. If row 
processing 1s NOT done after an END or RETURN command, the user 
will be allowed to exit the table display without correcting er- 
rors which have previously been detected. If row and command 
field processing IS done before allowing the END or RETURN to take 
effect, a CANCEL for equivalent) command should be provided to al- 
Jow the user a chance to abort the operation. 


Using CANCEL is suggested since it is consistent with EDIT. 


Any variable which is specified in a MODEL line but which is not 
part of the actual table (as defined using the TBCREATE service) 
must be cleared before each re-display of the table. It is recom- 
mended that this be done in the INIT section as opposed to the 
REINIT section or in a CLIST, EXEC or program. This prevents 
propagation of the value of the variable in one row of the table 
through each row of the displayed table. (This type of variable 
is often used to display a SELECT CODE field for line commands) . 


The enqueue mechanism provided by ISPF is intended to prevent con- 
current updating of the same table by multiple users. The mech- 
anism is based on the assumption that al] users updating a given 
table will have the same first library definition for ISPTLIB. 
Dialog developers should be aware of this when designing dialogs 
which will be used by concurrent users to update a table. A re- 
commended approach to alleviate this problem is to use the LIBRARY 
parameter on the TBOPEN, TBCLOSE and TBCREATE service. A unique 
ddname can be allocated to the input and output tables so that 
conflicts don't arise with ISPTLIB concatenation and ISPTABL. Us- 
ing the LIBDEF service provides another mechanism by which this 
can be done to reduce confusion and conflicts. 


Make certain that you sort the table in a sequence that will be 
logical to the user before displaying it. If possible sort and 
store the table as it will be referenced. 
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11. When a table is being accessed for the READ only, make sure that 
the NOWRITE option is specified on the TPOPEN service. This will 
insure that the table can be accessed concurrently for input only 
by multiple users. 


©) 
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6. FILE TAILORING 


6.1 GENERAL 


Each installation should examine the use of file tailoring in the de- 
velopment of their dialogs for on-line applications; misuse or inap- 
propriate use of this facility can significantly degrade performance. 


6.2 SPECIFIC 


1. Skeletons should be commented, just as programs, CLISTs, EXECs and 
panels should be commented. 


2. Use temporary ISPF output files wherever possible as opposed to 
handling permanent allocations. 


3. When referencing a temporary output file use the ddname supplied 
in the ZTEMPN system variable as opposed to the dsname in ZTEMPF. 


This will provide more flexibility especially when the temporary 
file is allocated to VIO. 


kh. Avoid using )IM. It complicates debugging; use FTINCLs. Also, 
always check the return code from the the FTINCL calls. 


5. The complexity of skeletons should be limited, just as the com- 


plexity of programs are limited for the purposes of understanding 
and maintenance. 


6. Tabbing, blank lines (") BLANK") and alignment should be used to 
keep generated output, as well as skeleton source, readable. 


7. The '')CM" statement should be used to document: 
a. Which dialog components use the skeleton. 


b. How the output file is used. 


c. Any unique features of the skeleton or environment. 
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If EDIT or BROWSE is going to be used on the output dataset then 
the file tailored output dataset cannot be VIO. If the output is 
to be BROWSEd or EDITted then make sure the ISPCTLx dataset (s) are 
‘allocated to real DASD. In all cases check the ZTEMPF and ZTEMPN 


variables to make sure that a real dataset is available for EDIT 
or BROWSE before attempting the operation. 
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7. MODELS 


SPECFIC 


Dialog developers should be strongly discouraged from making their 
own copy of the model menus (ISREMCMD, ISREMPNL, etc.). If they 
do create their own copies of these menus, they will not have ac~ 
cess to changes to these menus made in new versions of ISPF/PDF or 
changes made by the installation. Each installation should pro- 
vide a mechanism for users and/or groups to add their own models. 
This can be done by adding U (User) and G (Group) options to the 
model menus accessed by everyone in the installation. Following 
are two approaches to adding models. The first method is recom- 


mended because it does not complicate the MODEL command used to 
imbed the |1BM-supplied models. 


a. Method 1}: 


Place User and Group options on the Class menu and User, 


Group, and Installation options on the model options menu for 
each class. 


Advantages - Standard {SPF models are accessible at the first 
level of the hierarchy (e.g. the TBCREATE model can be im- 
bedded in a CLIST using the command 'MODEL TBCREATE'). 


Disadvantages - User models are placed one level lower in the 
hierarchy than the 1!BM models. 


b. Method 2: 


Insert a menu between the Class menu and each of the option 
menus. On the inserted menu, place options for ISPF services 
and Installation, Group and User options. 


Advantages - All model options are at the same level in the 
hierarchy; the model hierarchy can be organized more’ log- 
ically. 

Disadvantages - The command used to imbed a model into a data 


set (without displaying the model menus) requires an addi- 
tional qualifier to identify which section the model be- 
longs to (ISPF, Installation, Group or User). For example: 
the command required to imbed the TBCREATE model would be 
MODEL 1.TBCREATE if IBM-supplied ISPF models were option |. 
Also, if users are not familiar with which models are 
IBM-supplied ISPF and which are ‘home-grown’, they may have 
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to search one section before discovering that it Is con- 
tained in the other. This search may be frustrating be- 
cause an 'END' command on any model menu terminates the 
entire MODEL command. 


Within the skeleton member, NOTEs should be included to explain 
any options or parameters available to the user or areas which 
need to be customized by the user. The text within NOTE lines 
should be in mixed upper and lower case to improve readability. 


All models which are longer than ten lines should begin with a 
NOTE that explains the use of the model. 
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8. USER CUSTOMIZATION OF SYSTEM-WIDE DIALOG COMPONENTS 


GENERAL 


Dialog developers should be strongly discouraged from overriding 
system-wide dialog components with their customized version of 
these components. When ISPF users are allowed to override system- 
wide components, two problems occur: 


a. System-wide components are inadvertently overridden by users, 
resulting in dialog errors which can be difficult to diagnose. 


b. When modifications are made to dialog components in the 
system-wide libraries, the user-customized components prevent 
the user from seeing new or enhanced features. The most com- 
mon examples of this are user-customized Primary Option menus. 
A user overriding the Primary Option menu is unaware of 
changes or additions which have been made in the menu in the 
system-wide libraries. 


A program which front-ends the ISPF command processor can be used 
to enforce a concatenation sequence which your installation has 
defined as standard. 
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9. CONCATENATION SEQUENCES FOR ISPF LIBRARIES 
A standard concatenation sequence for ISPF libraries should be estab~ 
lished by each installation. For purposes of this discussion, we have 
identified four categories of libraries: 


1. (IBA-supplied ISPF and/or |ISPF/PDF libraries 

2. System wide applications (Installation-developed and Vendor) 
3. Group applications (Installation-developed and Vendor) 

4. User applications (Installation-developed and Vendor). 

Two methods exist for allocating and concatenating ISPF libraries: 


1. Pre-allocation of the ISPF files via: 
a. DDNAMES in the TSO logon proc. 
b. TSO ALLOCATE commands. 
c. LINK and ACCESS the ISPF minidisks. 
d. CMS FILEDEF commands. 


2. Using the ISPF LIBOEF facility. 


Each installation must determine how they are going concatenate al| 


the datasets used by ISPF for each user. The following an serve as 
guidelines: 


1. IBM supplied libraries for tSPF and PDF should be pre-al located 
for all users. 


2. Files supplied by vendors or which contain dialog elements written 
by an installation which are used by all or a large group of users 
should be pre-allocated to SPF. 


3. Vendor or installation written dialogs which need to be limited to 
a subset of users can be either pre-allocated just by the users 
who need to execute them or the ISPF LIBDEF facility can be used 
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to dynamically allocate the the appropriate files prior to select- 
ing the dialog. Reasons for limited dialog access are: 


a. Only one group needs access to a particular vendor-supplied 
application. 


b. One group has purchased its own vendor-supplied application 
and does not want anyone else to have access to it. 


c. One group has purchased a proprietary application and is re- 


stricted by the licensing agreement to be the only users of 
the application. 


If an installation has many ISPF files consider using LIBDEF to 
allocate libraries for infrequently used applications. Pre- 
allocating many ISPF libraries increases ISPF initialization over- 
head since it must open each one every time ISPF is invoked. 


If the total number of ISPF files is not great, pre-allocating may 
simplify the maintenance of the system. 


lf an installation modifies IBM dialog components, do so to a file 
other than the one distributed by IBM. This will insure that your 
changes are not removed by routine IBM system service (IBM's 
panel, message, skeleton and table files are al] SMP maintained in 
MVS; maintenance to VM mass replaces distributed dialog elements). 


Consider using a similar technique for any non-|BM supplied vendor 
package. 


Each installation is encouraged to protect any proprietary or company 
sensitive dialogs with external security. Do not rely on the ISPF li- 
brary concatenations to limit access to dialogs. 


An 


installation may wish to consider the LIBDEF service to break up 


elements for different dialogs. 


Advantages of using LIBDEF: 


l. 


Allocation of files can be deferred until the dialog is invoked. 
This reduces ISFP initialization overhead. 
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2. %ISPF initialization overhead is reduced since some ISPF files do 
not have to be allocated (they will be allocated later by LIBDEF). 


3. Dialog elements can maintained in their own libraries. This may 
simplify maintenance of the dialogs. 


4, The libraries are only allocated by the individuals executing the 
dialogs, not all ISPF users. 


Disadvantages of using LIBDEF: 
}. Additional overhead when selecting a dialog which uses LIBDEF ser- 


vices. 


2. Constant allocation and unallocation of files when entering = and 
exiting a dialog which uses LIBDEF. 
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10. CLISTS 


10.1 GENERAL 


CLISTS can be used in dialogs to speed development and ease mainte- 
nance. It is, however, an interpretive language and its use must be 
weighed against performance concerns. If a requirement of a dialog is 
faster execution than a non-interpretive language should be used 
(COBOL, FORTRAN, ASSEMBLER, PL/1, etc.) 


A developer may elect to write a dialog initially using clists and 
later re-write that portion of the dialog in a more efficient lan- 
guage. 


10.2 SPECIFIC 


1. CLISTs should be invoked by prefixing a percent sign (%/ to the 
CLIST name: 


%clistname 


If the percent sign is not used to invoke a CLIST, line mode dis- 
play 1s initiated and the screen is cleared. 


2. Global clist variables should not be used by CLISTs which are part 
of a dialog. ISPF variable services should be used. 


3. ATTN exits should not be used in ISPF CLISTs; their use will cause 
unpredictable results. 


4. The TERMIN command procedure statement is not supported under ISPF 
and must not be used. 


5. ISPF file-tailoring and the PDF edit-macro facilities should be 
used to format output dataset (JCL, input or output files, control 
cards, etc.). The use of TSO EDIT in a CLIST to perform such 
functions should be discontinued in favor of using these standard 


facilities, which are specifically designed for tailoring output 
data. 
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6. An installation may consider using the LIBDEF service instead of 
TSO ALLOCATE commands. This may simplify migrating from CLISTs to 
other programming languages or to VM (REXX or EXECs). 
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&ZUP 25, 29 
4 
% sign 
See CLISTs 
A 
ATTN exits 
See CLISTs 
C 
CLISTs &g 


% sign, invoking a CLIST with 49 
ATTN exits 49 
file tailoring vs. TSO EDIT 49 
global variables 49 
line mode display 49 
TERMIN command 49 
command line 
See panels 
confirmation panels 
See panels 
customization 
See ISPF libraries 


D 


default attribute character 

See panel, attribute character 
directive line 

See panels 
dynamic areas 

panels 19 


E 


END command 
See tables 
extended data stream 
See panels 
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F 


file tailoring 
batch vs. on-line execution 39 
skeletons 39 
uses of 39 
function line 
See panels 


G 


global variables 
See CLISTs 

graphic areas 
See panels 


H 


HELP 
See panels 


information panels 
See panels 
Instruction line 
See panels 
intensity 
See panels 
ISPF libraries 
concatenation sequence 
enforcing installation standard 43 
customization of system-wide ISPF components 43 
ISPTLIB 
See tables 


L 


LIBDEF 4&5, 46 
library concatenation sequence 4&5 
line mode display ; 
CLISTs 49 
long message line 
See panels 
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member names 
See naming standards 

menus 
See selection panels 

messages 31 
alarm 32 
default message area 3] 
designing 31 
format 31 
help panels 32 
informative 32 
message data set blocksize and member size 32 
optimizing message retrieval 32 
output facilities 31 
overlaying panel fields 31 
positioning the cursor 32 
punctuation 3] 
vocabulary 3) 

messages in table displays 
See tables 

models 4] 
adding models and classes 4&1 

model hierarchy 41 
two possible methods 4] 

NOTE lines 42 


N 


naming standards 3 
examples 6 
identifiers 
dialog id 4 
group id 4& 
system id 4 
type 5 

member names 4& 
IBM standard 7 
messages 6 

variables 3 

non-display panels 
See panels 


0 


option line 
See panels 
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panel design 
See panels, design considerations 
panels 9 
appearance 9 
command line 10 
confirmation 24 
description field, for input fields 13 
design considerations 18 
directive line 16 
menus 17 
non-scrollable panels 16 
scrollable panels 17 
tutorials 17 
dynamic 26 
dynamic areas 19 
extended data stream 18 
fields 12 
function line 11 
general layout 9 
graphic areas 26 
HELP 18 
information, on input fields 14 
informational 23 
input fields 13, 19 
input fields, repeating 14 
instruction line 11 
intensity 18, 19 
long message line 10 
multi-column data entry 22 
non-display 30 
non-scrollable 2) 
padding character 13, 15 
scrollable 11, 26 
sections 19 
select field 15, 19 
selection panels 27 
option line 27 
standard arrow symbol 13 
table display 26 
text fields 15 
text lines 16 
confirmation 16 
informational 16 
tutorial 16 
title line 9 
TRANS 19 
TRUNC 19 
tutorial 1] 
tutorial menu 29 
tutorial text 25, 29 
types 12 
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PFSHOW 18 
pre-processed panels 19 


repeating input fields 

See panels, input fields 
RETURN command 

See tables 


bs) 


screens 
See panels 
scrollable panels 
See panels 
selection panels 
See panels 
singly occurring 
See panels, tnput fields 
SMP (System Modification Program) 
member name requirements 3 


T 

table display panels 
See pane] 

tables 35 


command field processing 36 
extension variables 35 
ISPTLIB enqueue 36 

messages 35 

MODEL line 36 


processing the END or RETURN command 36 


processing user-modified rows 36 
providing a CANCEL command 36 
scroll] PF keys 35 

select code field' 36 

TBCREATE service 36 


values propagated through table rows' 


TBCREATE service 
See tables 
TERAMIN command 
See CLISTs 
title line 
See panels 
TRANS 19 
TRUNC 19 
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36 


INDEX 


TSO EDIT 

See CLISTs 
turorial menu 

See panels 
tutorial text panel 

See panels 


V 


variables 
See naming standards 
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